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Chapter 1 


Stacks 


1.1 Introduction 


One specific type of List we often deal with is known as a Stack. The idea behind a Stack in 
computer science is the same as that of stacks in real life. There are a collection of elements, 
arranged in linear order, and you can only access the top element of the set. 

A good example of stacks is a pile of papers on your desk. You can very easily add a paper 
to the top of the pile; likewise, you can very easily remove the top paper, or even read it without 
removing it. However, if you try and pull a paper out of the middle of the pile, you are likely to 
topple the entire pile and end up with papers all over the floor, and thus pulling a paper out of 
the middle of the pile is probably not a good idea. 

When we use the Stack ADT, we will have the same constraints. We will have a particular 
end of the linear arrangement of elements, which we will call the top of the stack. It will be 
possible to insert a new element onto the top of the stack. Likewise, it will be possible to remove 
the element at the top of the stack, or even read it without removing it. But, the only way to 
access elements other than the top element will be to remove enough elements from the stack 
that the element we are after becomes the top element. 


1.2 The Stack ADT 


The three operations listed above — insert at top, remove from top, read top — are the three 
major operations in the Stack ADT. These operations have specific names: 


Push(X) -- insert X as the top element of the stack 
Pop() -- remove the top element of the stack and return it 
Top() -- return the top value of the stack without removing it 


from the stack 


There is a problem here, however. Pop() and Top() must return a value. What happens 
when there is no value? When dealing with a List, we would run into the same problem with 
Retrieve() and Update(X) — functions which only worked if there was an element to work on, 
and thus didn’t work on a dummy element or an empty list. 

So, what happens when we call Pop() and there is no value? Or, better yet, how do we 
avoid doing this in the first place? What we need is some way of determining that the stack is 
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empty. If the stack is empty, we simply won’t call Pop(). In the List class, we had a Length() 
function; we could have the same function here if we wanted to, but we can get by just fine 
with a function that only tells us if the stack is empty or not. So, that will be our fourth ADT 
function. 


IsEmpty() -- returns TRUE if stack is empty, FALSE otherwise 


This way, the programmer can have the program decide whether or not to call Pop() or 
Top() at run-time. This would be done by having the program use IsEmpty() to check if the 
stack was empty — Pop() or Top() would not be called unless the stack was not empty. 

Those operations are really the only operations in the ADT. A language like C++ would 
generally require the usual additional set of operations — constructors, destructor, operator= 
— and the user might possibly decide to add a Length() or Size() function in place of or in 
addition to IsEmpty (), but the core ADT is basically the four operations above, and there is 
little, if any, change in those operations across various different users’ Stack ADTs. 


1.3. Implementing Stacks 


1.3.1 Contiguous Memory 


We have seen that the worst case for insertion and deletion from an array occurs when we insert 
or delete from the beginning of the array. Conversely, the best case occurs when we insert or 
delete from the end of the array, because in this case we don’t need to shift any elements, and 
thus the operation takes constant time. Since the insert and delete operations for a stack — i.e., 
Push(X) and Pop() — will both take place at the same end of the array, it makes sense to have 
these operations work at the end of the array rather than the beginning. By doing this, we can 
have the two operations work in constant time. 

So, when implementing a stack using contiguous memory, we can have the operations work 
in much the same way as we did for the contiguous implementation of the list. The difference 
is that we know we only need to code for one specific case — the case where our insert or delete 
deals with the last element of the array. 

Therefore, a stack represented in picture form would be represented in actual contiguous 
memory as indicated below: 
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Figure 1.1: An abstract stack and its contiguous implementation 


In the case of contiguous memory, it is possible for the available memory to “fill up” if we 
insert enough elements, so in that case we sometimes add a fifth function to the ADT — IsFul1() 
— which returns TRUE if the stack is full and FALSE if it is not. We would call this function 
before calling Push(X), just as we would call IsEmpty() before calling Pop() or Top(). 


1.3. IMPLEMENTING STACKS 
The operations would work as follows: 


Etype Pop() 












































{ 
Etype tempElem = A[current] ; 
current—- ; 
return tempElem; 
} 
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Figure 1.2: The above stack after a Pop() operation 


void Push(Etype newElem) 
























































{ 
current++; 
A[current] = newElem; 
} 
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Figure 1.3: The stack if a Push(7) is performed after the Pop() 


Etype Top() 
{ 

return A[current]; 
int IsEmpty () 


{ 


return (current==-1); 
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And, if we wanted an IsFull() function, we would also want to store a value that held the 
size of the array. The array indicies would range from 0 through size — 1, and so if the current 
index was equal to size — 1, it would mean that the stack was full. 


int IsFullQ 
{ 


return (current == size - 1); 


A quick examination should show that all five operations merely perform a few constant time 
operations and thus all run in constant time. 


1.3.2 Linked Memory 


For the linked implementation, we want to do the same kind of analysis we did for the contiguous 
implementation — namely, we want to decide where the insert and remove operations would run 
the fastest, and put our stack operations there if we can. 

For a singly-linked list, we were able to insert at either end of the list in constant time. 
Removal, however, was only constant time if we were removing from the head of the list — 
removal from the end of the list took O(n) time. So, since we can either place the stack 
operations at the head of the list or at the end of the list, it makes the most sense to place them 
at the head of the list, where both insertion and removal take constant time. 

Since we are only performing operations at the front of the stack, there is no need for a 
current pointer — all we will need is the head pointer. Hence, the translation from picture to list 
looks as follows: 
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Figure 1.4: An abstract stack and its list implementation 


The operations would work as follows: 


Etype Pop() 
{ 
Etype returnElem = head->element; 
Node* tempPtr = head; 
head = head->next; 
delete tempPtr; 
return returnElem; 
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Figure 1.5: The above stack after a Pop() operation 


void Push(newElem) 


{ 
tempPtr = new Node(); 
tempPtr->element = newElem; 
tempPtr->next = head; 
head = tempPtr; 

ay 
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Figure 1.6: The stack if a Push(7) is performed after the Pop() 
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Etype Top() 


{ 

return head->element ; 
} 
int IsEmpty () 
{ 

return (head == NULL); 
} 


Since we are only doing a few arithmetic and pointer operations in each function, all functions 
run in O(1) time. 


1.4 Choosing between implementations 
Since both implementations support all operations in constant time, is there any reason to use 


one of the implementations over the other one? The answer is yes, but the differences here are 
more subtle than they were for the List implementations. 
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For the linked implementation, we are forced to allocate and deallocate a node each time 
we perform a Push(X) or a Pop(). This allocation is constant time, but it is not immediate — 
that is, allocating a node and writing into it does take longer than writing into a pre-allocated 
cell. So, the contiguous implementation has a bit of a speed advantage — the memory is already 
allocated, and so we simply write values into the existing cells, rather than trying to allocate and 
deallocate memory with each operation. The speed difference is not apparent if we only consider 
the order of the operation, but if we consider constant factors as well (recall that constant factors 
are hidden by Big-O notation), then the contiguous implementation will be slightly faster for a 
given Push(X) or Pop() operation. 

On the other hand, the linked implementation has a more graceful memory usage. We are 
using only as many nodes as we need, whereas for the contiguous implementation we are forced 
to allocate a lot of space ahead of time. In addition, if we run out of space in the array, we 
either must stop doing inserts, or else proceed with an expensive (linear time) dynamic increase 
of the array size. The linked implementation can increase available memory node-by-node, and 
will only run out of space when all the actual system memory is used up. So, the linked list has 
more graceful memory usage. 

One interesting note — if memory usage is your only concern — if you need to save every last 
bit of memory, regardless of the time it takes to do so — then since the linked implementation 
uses pointers as well as space for the value, you would be better off with an array. With 
this array, you would allocate only the memory you need — essentially performing a dynamic 
bounds change on the array with every Push(X) and Pop() operation. This would make the 
two operations O(n), but it would be the most efficient use of memory we could achieve. The 
only time this strategy would be appealing as a way to save memory would be if we wanted to 
save memory even at the expense of our constant time running times for the stack operations. 
If we want graceful memory usage and also good running times, then we want to go with the 
linked implementation, and would need to be willing to use the extra pointer memory that such 
an implementation would need. As always, the correct decision will depend on the particular 
circumstances of your environment and your application. There is no single catch-all correct 
answer. 


Chapter 2 


Queues 


2.1 Introduction and ADT 


A stack is often referred to as a LIFO structure — the acronym stands for “last in, first out”. In 
contrast, a queue is sometimes called a FIFO structure — a structure that follows the “first in, 
first out” rule. A queue, like a stack, is a linear structure for which you can only insert on one 
end and can only remove from one end. The difference is that for a queue, these are different 
ends. Elements are inserted only into one end of the queue, and are removed only from the other 
end. 

The only difference between the Stack ADT and the Queue ADT is the naming of the 
operations, and the place where the insert operation places values. Each Stack operation has 
an analogous Queue operation with (usually) a different name. Otherwise, everything that was 
said for the Stack ADT applies equally well for the Queue ADT. 


Enqueue(X) -- place X on the rear of the queue 
Dequeue() -- remove the front element of the queue and return it. 
Front() -- return the front element of the queue without removing it. 


IsEmpty() -- return TRUE if the queve is empty, FALSE otherwise 


2.2 Implementing Queues 


2.2.1 Linked Memory 


Just as with Stack, you can implement Queue using a linked list. Again remembering that insert 
works in constant time on either end of the list, while remove works in constant time only at the 
front of the list, it seems best to have the head of the list be the front of the queue, and to have 
the end of the list be the rear of the queue. This way, all our removes will be from the front of 
the list, and all our insertions will be at the end of the list — making both operations constant 
time. The queue represented as linked memory thus appears as below: 
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Figure 2.1: An abstract queue and its linked implementation 





















































The operations are as follows: 
Etype Dequeue() 


Etype tempElem = head->element; 
Node* tempPtr = head; 

head = head->next; 

delete tempPtr; 

return tempElem; 
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Figure 2.2: The above queue after a Dequeue() operation 


void Enqueue(Etype newElem) 


t 
current->next = new Node(); 
current = current->next; 
current->element = newElem; 
current->next = NULL; 
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Figure 2.3: The original queue, with an Enqueue (9) following the Dequeue() 
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Etype Front () 


{ 

return head->element ; 
} 
int IsEmpty () 
{ 

return (head == NULL); 
} 


2.2.2 Contiguous Memory 


For contiguous memory, it would appear we are stuck. Both insertion and removal are O(n) 
from the front of an array, but we need to use both ends of the array — unlike the stack, where 
we needed only one end of the array — and so there is no avoiding having an operation on the 
front of the array. Therefore, it would appear we are forced to accept having an operation take 
O(n) time. 

The solution that gets us around this problem would appear to be to not shift values on a 
remove. Since insertion in the front of an array requires us to make space for the new element, 
and removal simply leaves space open, let’s put removal at the front of the array, insertion at 
the end of the array, and when an element is removed, simply leave the elements exactly where 
they are. Instead of shifting values, we simply leave the values to the left of the queue empty as 
the queue itself moves toward the right end of the array. If we have variables that tell us where 
the front and rear of the queue are located, the other values can just sit in memory and we can 
ignore them once they are officially removed from the queue. 
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Figure 2.4: An abstract queue and a possible contiguous implementation 


Enqueue (6) ; 
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Figure 2.5: The queue reaches the other side — no more room! 


Well, now we have removal and insertion both running in constant time, but we’ve created 
a new problem — the queue has shifted in the array due to insertions on one end, and removals 
from the other. Now, we have no more room to insert new elements, even though the queue 
is not full. Furthermore, we have wasted space in the front of the array that we could use for 
insertions, if only we could make use of it and still keep our abstract picture intact. 

The solution? Allow the queue to “wrap around” from the end to the front (similar to 
Pac-Man!). The basic idea is to picture our array as a circular array. 
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Figure 2.6: The previous “filled” array, represented as a circle 


Now, cell 0 naturally follows cell 6, and insertions and removals can proceed as always. 
Whatever space we leave empty with removals can be claimed by the insertions very easily, once 
the array is prepared to make use of that space. 

Essentially, we can increment front and rear as we did before, but if we increment to a 
point where the index held is no longer a real array index, then instead set the index to 0. 
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Figure 2.7: A Dequeue() and a “wrap-around” Enqueue (10) 


front = front + 1; 
if (front == size) 
front = 0; 


However, we don’t even need an if-statement. We can simply take advantage of modular 
arithmetic. Any number from 0 to n — 1, modulus n, will be the number itself, and n modulus 
n will be 0. This is exactly what we want! 

The following examples show a sequence of queue operations on a circular array. 
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Figure 2.8: Our starting circular array 


Etype Dequeue() 















































{ 
Etype tempElem = A[front]; 
front = (front + 1) % size; 
numElements = numElements - 1; 
return tempElem; 
} 
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Figure 2.9: The result of Dequeue() 
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void Enqueue(Etype newElem) 
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Figure 2.10: Next, an Enqueue(9) 


























{ 
rear = (rear + 1) % size; 
A[rear] = newElem; 
numElements = numElements + 1; 
} 
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Etype Front () 
{ 
return A[front]; 


} 


int IsEmpty () 
{ 
return (numElements == 0); 


+ 


int IsFull(Q 
{ 


return (numElements size); 


} 


All of these operations are constant time, and therefore we are making efficient use of the 
array. 
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2.2.3. Choosing between implementations 


The decision of whether to use the contiguous or linked implementation for a queue will basically 
follow the same line of thought as the similar choice did for stacks. So, there is no need to restate 
the arguments here — the trade-offs one has for stacks are the same trade-offs one has for queues. 


2.3 One final note 


The code segments presented in this packet — both in the stack section and in the queue section 
— are all pseudocode. For the most part it is correct, but the occasional detail has been left out 
— most notably inserting into an empty linked list. We have presented the general cases, and 
any specific cases are left as an exercise for you. 


